Combining Silos and Bridges to Organize for Agility

By Michael Levine

“Break down the silos!” was a leadership mantra from a decade ago, championed by the era’s leading executive, Jack Welch at General Electric. Today’s hot idea is to keep teams small enough to feed with two pizzas, championed by Jeff Bezos at Amazon.

Truth is, you need both to foster organizational agility. Combine Welch’s boundary-less organization and Bezos’ tightly bound small team, and you have the means to not only create and support the right kind of small teams, but effectively bridge them to each other and to the broader organization.

Build the Right Silos

Welch believed that lack of cooperation across business units hindered GE from mobilizing its full capabilities in service of its customers. He fought to tear down silos between functional departments — sales and operations; marketing and finance. But he certainly believed GE should have business units, with each sharply focused on profitability and growth for a specific set of customers and products.

The right kind of silos foster productivity, expertise and focus within. Experience, especially from the agile software movement, tells us that the right kind of small team has coherence around a business goal rather than around a function. For example, the test lead on a scrum team should primarily focus on the team goal, while leveraging expertise or tools as needed from a broader testing department.

But there is only so much a two-pizza team can accomplish. To get larger things done, we need to bridge the silos, and keep our leadership for agility goals of rigor, alignment, and efficiency front of mind. Here are two ways to do that:

Bridges Within a Single Initiative

The simplest is to create bridges between silos within a single context: multiple teams working together on a product like Slack or Salesforce, or a large program within a manufacturing or financial firm.

Consider this example: A large financial institution implements a comprehensive new system to improve business financial services. The broad team includes over a hundred participants from sales, operations, credit, compliance, risk, change management, development, testing and deployment. Silos are established in general alignment with the two-pizza rule based on many factors, including those unique to this initiative and this company. The silos mix functionally focused (sales, underwriting, customer digital, change management) and technical (testing, devops, integration).

Then bridges are laid down with rigor, alignment and efficiency in mind. These kinds of bridges apply to most multi-pizza teams focused on a common goal, and include:

• Clear, repetitive leadership communication on shared goals and schedules.
• Shared physical space.
• Program structure, including daily meetings of team leads and other governance.
• Common backlog in a shared tool.
• Common sprint schedule, and shared demos at sprint end.
• Common environments for development and testing.
• Shared communication tooling, including visuals in the rooms, conferencing and texting, and documentation storage.
• Master test strategy developed and communicated across teams.
• Organizational structure. Multiple participants from a single discipline (e.g., Sales) report to common managers, who stay involved and help with communication and governance. These managers also staff the teams initially, and deal with changes over time.

Bridges Across the Enterprise

A large enterprise needs to both isolate and connect its program teams just as they have traditionally done with business lines. Teams need to have the right information flowing in and out in order to make good decisions, gain efficient contribution from those who can help, and ensure adoption.

Beyond the intra-initiative bridges identified above, enterprise bridges should also include the following.

• Formal management reporting hierarchy. For example, the devops team members may remain part of the broader enterprise tech ops department. That structure enables them to more easily bring new capabilities to the team, and to raise team problems to experts.
• Governance structures. A formal governance group for each major initiative allocates senior leadership accountability, providing a routine forum for cross-functional collaboration and connection making. The self-managed team is a good concept, but senior executives can still help.
• Informal relationships. Team members and their managers should reach out to their peers and partners, establishing routine relationships across functions and even companies. In tough times these relationships unlock keys to rigor, alignment, and efficiency.
• Statements of Work. This concise, somewhat standard document lays out the what, why, when, how, and who of each major initiative, and provides a framework to establish rigor and efficiently enable engagement.
• Status reports. A major goal of the two-pizza team is empowerment, but in practice, and if done well, “trust but verify” improves rigor and alignment.
• Transparency. Each team’s work should be visible, as touted at Slack, where channels are typically open to review. But along with transparency, there still needs to be outgoing outward communication.
• Inherent enterprise structures. Large traditional companies often have an enterprise release for widely used shared systems. Control mechanisms for these releases can help teams align, much as the very existence of these periodic large release events can impede agility. On the other end of the spectrum, a microservice API-centric technology architecture like Amazon’s can minimize the need for cross-team communication and coordination.

Since the Manifesto for Agile Software Development was promulgated some twenty years ago, our primary concern has been the creation and functioning of our agile teams, especially on the scrum process. It’s time to put People and Interactions over Processes and Tools. Organizational leaders have an obligation to help form the right kinds of teams, and then properly connect them to the broader organization and external partners. By designing and supporting context-appropriate silos and bridges, leaders honor the first agile value — and the primacy of our people and their interactions.

Michael K. Levine is an expert on lean and agile software development and information technology. He’s worked at the US Commerce Department, First Bank System, and Norwest Banks; was CTO of a real estate software firm; and led Wells Fargo servicing technology through the default crisis. In 2011 he joined US Bank to deploy a new branch banking system; then was technology lead at US Bank Home Mortgage. He now leads all consumer lending and business banking technology. His latest book is People Over Process: Leadership for Agility (Productivity Press, September 30, 2019). He lives in St. Paul, Minnesota. Learn more at TheTalesofAgility.com